Architecture d’un entrepôt de données

Pourquoi un entrepôt de données ?

On construit les entrepôts de données pour permettre aux gens de prendre de meilleures décisions. Le principe est simple : un meilleur accès aux données permet de prendre des décisions plus éclairées. Évidemment, il faut que les données soient fiables et compréhensibles. L’entrepôt de données intègre fréquemment plusieurs données de sources différentes. En effet, il ne suffit pas d’avoir l’information, encore faut-il avoir toute l’information et pouvoir établir des relations entre différentes données.

Qu’est-ce qu’un entrepôt de données ?

Il s’agit d’un ensemble de bases de données qui intègrent des sources de données hétérogènes (provenant de diverses sources) et non volatiles (qui ne changent pas fréquemment). Les données sont pratiquement toujours temporelles : l’entrepôt permet de voir comment diverses variables organisées par sujet (comptabilité, marketing, etc.) évoluent dans le temps.

Sémantique et nettoyage

Il est difficile en pratique de combiner des données provenant de services différents. Par exemple, il n’existe souvent pas une définition uniforme au sein d’une entreprise quant à ce qui constitue un « profit ». Il est fréquent que des normes comptables différentes mènent à des résultats différents. C’est notamment le cas des gouvernements où l’opposition ne s’entend pas toujours avec le parti au pouvoir sur les définitions comptables permettant de définir le déficit ou le coût d’un programme. Ainsi, deux services peuvent définir différemment la région de Montréal.

Ces problèmes sont de nature sémantique : les gens ne s’entendent généralement pas toujours sur le sens des mots. Parfois, il peut même être difficile de comprendre exactement ce qu’une mesure donnée signifie. Un département des ventes pourra affirmer qu’un vendeur a un « indice de productivité de 0,75 ». Que signifie cet indice ? Si on veut utiliser de telles données dans un entrepôt, il faut être capable de documenter la signification des termes utilisés.

Pire encore, le sens des termes peut évoluer dans le temps, ou de nouvelles mesures peuvent apparaître. Une entreprise peut être sujette à des réorganisations fréquentes ou les projets qu’elle porte peuvent être de courte durée.

Si on change subitement les normes comptables, comment un entrepôt peut-il tenir compte de ces changements tout en permettant une analyse longitudinale de l’entreprise ?

Finalement, les données elles-mêmes peuvent être fausses. Par exemple, il est fréquent qu’on saisisse mal les données. Vous avez sûrement déjà constaté qu’une entreprise a mal saisi votre nom, votre adresse ou d’autres informations vous concernant ? Lorsque ces informations sont utilisées pour des analyses, on peut obtenir des résultats faussés qui peuvent mener à des mauvaises décisions. Si, par mégarde, 40% des clients de la Rive-Sud de Montréal sont identifiés comme des résidents de l’Ontario, les analyses fondées sur ces informations pourront être trompeuses. Pire encore, il peut être difficile de retracer la source du problème (ou même de détecter le problème) sans revenir à la source et aux données elles-mêmes.

Il n’y a généralement pas de solution miracle à ces problèmes de sémantique ou de données erronées. Mais plusieurs stratégies peuvent être employées :

– On doit, autant que possible, avertir les utilisateurs de conflits sémantiques pouvant rendre l’interprétation des données difficiles.
– On peut tenter de mettre à profit la collaboration des utilisateurs. Ainsi, au lieu de tenter de mettre sur pied un schéma de données cohérent, on peut demander aux utilisateurs d’en proposer un et de discuter librement des possibles problèmes.

Une solution essentielle est la traçabilité.

La traçabilité

Depuis quelques années, dans l’industrie agroalimentaire, on fait la promotion du concept de traçabilité. En somme, lorsqu’un morceau de viande est vendu au consommateur, il faut pouvoir retracer la provenance de l’animal, et ce, jusqu’à l’endroit où il est né. Ainsi, s’il y a un problème avec le produit, on peut rapidement prendre des mesures correctives sans nécessairement devoir remettre en question la qualité de tous les produits dans un supermarché.

La même notion existe dans les entrepôts de données. Un gestionnaire d’entrepôts de données doit pouvoir, en tout temps, expliquer l’origine d’une donnée quelconque. D’où proviennent les données originales ? Quelles opérations de traitement furent effectuées ?

L’architecture

Un entrepôts de données est généralement un ensemble de données regroupées de manière logique. Par exemple, les données provenant de la comptabilité seront combinées avec les données provenant du département de marketing. Les données elles-mêmes peuvent être physiquement distribuées. En fait, les données peuvent même être stockées et traitées hors de l’entreprise, par un fournisseur externe (on parle alors parfois de Cloud Computing). L’entrepôt est cependant géré de manière centralisée.

On peut aussi, au sein de chaque service d’une entreprise, mettre sur pied un entrepôt de données spécialisées, appelé data marts ou « magasin de données ». Cet entrepôt est plus facile à créer parce qu’il n’a pas à combiner des données qui provenant de plusieurs services et exigeant donc une certaine conciliation. Puisqu’il peut cibler les besoins d’utilisateurs plus spécialisés, il peut être aussi plus simple d’utilisation.

On peut aussi combiner les différents data marts au sein d’un entrepôt de données qui sera alors fédéré : différentes parties de l’entrepôt sont alors sous la responsabilité de différents services.

Pour en savoir plus...

– L’article Data Warehouse dans Wikipédia.

– W. H. Inmon, Building the Data Warehouse, Wiley, 2005. (Inmon décrit une approche plus formelle des entrepôts de données. Certains ingénieurs la trouvent difficile à mettre en pratique. On la décrit parfois comme une approche « top-down ».)

– Ralph Kimball, The Data Warehouse Toolkit : The Complete Guide to Dimensional Modeling, Wiley, 2002. (La méthode Kimball semble faire l’unanimité parmi les ingénieurs travaillant dans les entrepôts de données. Kimball préfère une approche plus évolutive qui est parfois décrite comme étant « bottom-up » en opposition à la méthode préconisée par Inmon).

– Paulraj Ponniah, Data Warehousing Fundamentals : A Comprehensive Guide for IT Professionals, Wiley-Interscience, 2001.

– Thomas C. Hammergren, Data Warehousing For Dummies, For Dummies, 2009. (Comme l’indique le titre du livre, il n’est pas destiné aux informaticiens, mais plutôt aux gens d’affaires.)